Services for computing systems, such as subscription services available over the Internet, often cater to a wide audience of users via a user interface (UI). Each service typically sends data content to various users, including instructions for various products, help menus, pull-down menus, toolbars, etc. Users have very different needs, however, so a single version of any one UI configuration or data content is not likely to satisfy all users.
FIG. 1 shows a conventional scheme 100 for creating a number of monolithic user interfaces. Users 102 are roughly categorized into groups and each group provided with a monolithic UI that best approximates the group's characteristics and needs. The groups, however, are usually formed according to a single criterion—along one dimension—such as geographical region, with an assumption that the characteristics and needs of users that match the criterion in one dimension will be similar. Thus, users designated as “West Coast” are provided a UI version 104 that is assumed to meet the needs of a typical West Coast user. East Coast, North, South, and Midwest users are also provided with a version of the UI (106, 108, 110, 112, respectively) thought to best satisfy users 102 in these regions. If a second dimension is added, such as “product type,” e.g., for three different products, then in the monolithic model nine more UIs are needed, for each product, three more UIs for each geographical version of the UI (West Coast UI 104, East Coast UI 106, etc.).
This conventional scheme 100 for tailoring UIs and their content to users 102 has several more disadvantages. A certain data object 114 may be identical across UI versions or designed for use as a section of unchanging boilerplate across all versions of a monolithic UI. Thus, the data object 114 may be relatively unchanging even if the data object 114 appears in different positions within multiple UI versions (i.e., object versions 114, 116′, 116″, 116′″, 116″″). Such a data object 114 often has to be rewritten and stored anew for each monolithic UI version even though different instances of the data object 114 are identical or nearly identical in each version.
Data objects that do change significantly across different UI versions also have to be rewritten for each version. For example, data objects 116 and 118 may change across multiple UI versions (not shown), incurring significant effort when these data objects 116, 118 are large text corpora. So, one of the problems with conventional UIs is that they are often written as seamless wholes that require unique modification during update other versions of the UI also require their own separate update. Such conventional UIs may be very large objects in which various parts are hard coded into a given version.
Customer support tools provide one conventional example of the monolithic UI approach. Conventionally, UI customization for customer support tools is hierarchically dispatched along one dimension—a single group dimension, as described above. A group object is defined in order to consolidate a set of tools for users and data items that users can access via the UI, such as mailboxes, issue codes, flags, etc. This conventional scheme, however, is rigid because it does not allow objects to be shared across groups and requires duplicate objects to be created in each group where such objects are needed. For example, if the customer support tools use an “issue code” entity, then for each group, separate instances of an issue code connectivity tree are defined. These separate instances of a tree are more or less self-contained and have no common interaction. This means that the conventional scheme does not allow one part of a tree (e.g., the top level, or one branch, or one subset, etc.) to be shared between trees. If parts of the tree could be shared or made common, then the sharing would allow corresponding instances of the part to be updated across multiple trees just by updating one instance; would avoid constantly having to reproduce the same part; and would avoid the effort of reporting separately on different instances of the same part. Thus, although each group in this conventional scheme example has a connectivity issue code tree, the replicated tree is actually defined multiple times, and the multiple trees have no common or shared parts. So, each corresponding part has to be maintained separately and reported on separately.
Additionally, customization of customer support tools along one-dimensional groups does not allow a sufficiently granular adaptation of a given UI to different users—a user is subjected to an “all or nothing” model in which unneeded tools are offered or needed tools are lacking. The one-dimensionality of groups, and in turn UI customizations, also results in an explosion in the number of groups created and maintained to address the different customization requirements of customer support agents based on vendor site, country, locale, line of business, level, etc. In some instances, the motivation driving the multiplication of separate groups includes a desire to avoid a confusing abundance of unneeded options. If only a few large groups are used, there is the disadvantage that each group tries to serve too many different types of users. The explosion of groups can also be motivated by a desire to avoid potential security holes that are possible if a user has access to more information than needed in a monolithic group meant for too many different types of users.
Because of this, there is a need to more accurately customize UIs to the multiple characteristics and needs of various types of users and at the same time streamline the UI generation process.